問題文

あなたの元にWebサーバーの構築に関するトラブルシューティングの依頼が届きました。
ロードバランサーにアクセスをすると、正常なレスポンスが返ってこないことがあるようです。
ロードバランサーによる振り分け先のWebサーバーはセキュリティ上触ることはできませんが、
ロードバランサーへの接続情報は知っています。
このロードバランサーの設定を変更し、エラー表示がなくなるよう修正してください。

情報

ルーター・サーバーへのアクセス情報

踏み台VNCサーバから以下のサーバにアクセスすることができます。

1. Load Balancer
   Address: 192.168.0.1
   User: admin
   Password: 8NrV6CZei

ゴール

ロードバランサの設定を修正し、エラーが表示されなくなるようにする

復旧措置

ペナルティーによる減点はありません。

解説

この問題はNginxのupstream機能を使ったロードバランシングの問題でした。

まず、状況を確認するために、ロードバランサーにhttp GETリクエストを送ってみると、稀に500レスポンスが返ってくることがあります。
今回の問題では、実際にレスポンスを返しているアプリケーションサーバーには手を付けることができないため、ロードバランサーの設定を変更することでエラーが表示されないようにしなければなりません。
もう少し、詳しく状況を確認してみましょう。ロードバランサーの設定ファイルを確認してみると、upstream機能によって、192.168.0.11と192.168.0.12の2台にリクエストが振り分けられていることがわかります。
実際にcurlなどを用いてレスポンスを確認してみると、このうち192.168.0.11の方は500レスポンスは出さず、192.168.0.12で稀に500レスポンスが返ってくるというという状況にあることが確認できます。

192.168.0.12で稀に500レスポンスが返ってくるという状況であることから、パッシブヘルスチェックを用いて500レスポンスが返るときに、failoverされるように設定すると問題が解決できます。

解答例

upstreamによってリクエストが192.168.0.11と192.168.0.12に振り分けられていることがわかる。
それぞれをcurlコマンドによって確認したところ、192.168.0.12のサーバーのみから稀にエラーが返ってきた。
/etc/nginx/nginx.conf の proxy_pass http://ictsc-web; の次の行に

proxy_next_upstream error timeout http_500;

と追記することでNginxのパッシブヘルスチェックが行われ、500レスポンスが返ってきた際にフェイルオーバーすることができるようになる。
設定の編集後、 sudo systemctl restart nginx でNginxを再起動する。

採点基準

採点の際に、upstreamのserver 192.168.0.12;を削除する、という解答が多く見られましたが、これでは振り分け先が１つになってしまい、ロードバランサの役割をなしていないと考えたため30点の減点をしました。
また、192.168.0.12のサーバーをstandby状態にしておくという解答も見られました。今回の問題では192.168.0.11のサーバーではエラーが起こることはなく表面上問題が解決されたように見えてしまいますが、仮に192.168.0.11のサーバーでエラーが起こった際に、確実に稀にエラーが返ってくるように設定してある　192.168.0.12のサーバーにフェイルオーバーされてしまうため、50点の減点ということにしました。

講評

この問題への解答率は44.90%、解答があったなかで部分点を含め点数をつけたチームは86.36%、満点をつけたチームは31.82%でした。
他の問題に比べると難易度が低く設定されていたため、解答がなかったチームでも挑戦をしてみればなにか取っ掛かりが得られたのではないかと考えています。個人的には、解答率が予想より低く残念だと感じました。